Destabilise `target-spec-json` by davidtwco · Pull Request #150151 · rust-lang/rust

davidtwco · 2025-12-19T11:59:45Z

Per #71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std).

Current build-std RFCs (rust-lang/rfcs#3873, rust-lang/rfcs#3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc.

De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.

rustbot · 2025-12-19T11:59:49Z

These commits modify compiler targets.
(See the Target Tier Policy.)

rustbot · 2025-12-19T11:59:52Z

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Kivooeo · 2025-12-19T13:35:34Z

r? me

@bors r+ rollup

bors · 2025-12-19T13:35:37Z

📌 Commit 6c4c438 has been approved by Kivooeo

It is now in the queue for this repository.

…json, r=Kivooeo Destabilise `target-spec-json` Per rust-lang/compiler-team#944: > Per rust-lang#71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std). > > Current build-std RFCs (rust-lang/rfcs#3873, rust-lang/rfcs#3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc. > > De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.

Rollup of 7 pull requests Successful merges: - #149633 (Enable `outline-atomics` by default on AArch64 FreeBSD) - #149788 (Move shared offload globals and define per-kernel globals once) - #149989 (Improve filenames encoding and misc) - #150012 (rustc_target: Add `efiapi` ABI support for LoongArch) - #150116 (layout: Store inverse memory index in `FieldsShape::Arbitrary`) - #150151 (Destabilise `target-spec-json`) - #150159 (Split eii macro expansion code) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2025-12-19T22:38:35Z

@bors r-
#150168 (comment)

Kivooeo · 2025-12-19T22:53:25Z

I don't see why exactly it fails, but the problem in src/tools/cargo/tests/testsuite/rustc.rs in rustc_with_print_cfg_config_toml_env test

rustc is destabilising custom targets (rust-lang/rust#150151) and requiring that `-Zunstable-options` is passed when custom targets are used. This is the minimum change required so that the rustc patch can be merged.

davidtwco · 2026-01-05T12:11:29Z

Submitted rust-lang/cargo#16467 to adjust the Cargo test, then after the Cargo submodule update this will be able to be merged.

rustc is destabilising custom targets (rust-lang/rust#150151) and requiring that `-Zunstable-options` is passed when custom targets are used. This is the minimum change required so that the rustc patch can be merged.

@ghost

…uwer Rollup of 14 pull requests Successful merges: - #150151 (Destabilise `target-spec-json`) - #150826 (Add `f16` inline ASM support for s390x) - #150883 (Improve span for "unresolved intra doc link" on `deprecated` attribute) - #150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - #150943 (Port `#[must_not_suspend]` to attribute parser) - #150990 (std: sys: net: uefi: Make TcpStream Send) - #150995 (core: ptr: split_at_mut: fix typo in safety doc) - #150998 (Relax test expectation for @__llvm_profile_runtime_user) - #151002 (Remove a workaround for a bug (take 2)) - #151005 (Fix typo in `MaybeUninit` docs) - #151011 (Update books) - #151029 (rustc-dev-guide subtree update) - #151032 (fix: added missing backtick in triagebot.toml) - #151035 (Don't suggest replacing closure parameter with type name) r? @ghost

Rollup merge of #150151 - destabilise-target-spec-json, r=Kivooeo Destabilise `target-spec-json` Per rust-lang/compiler-team#944: > Per #71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std). > > Current build-std RFCs (rust-lang/rfcs#3873, rust-lang/rfcs#3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc. > > De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.

@ghost

…uwer Rollup of 14 pull requests Successful merges: - rust-lang/rust#150151 (Destabilise `target-spec-json`) - rust-lang/rust#150826 (Add `f16` inline ASM support for s390x) - rust-lang/rust#150883 (Improve span for "unresolved intra doc link" on `deprecated` attribute) - rust-lang/rust#150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - rust-lang/rust#150943 (Port `#[must_not_suspend]` to attribute parser) - rust-lang/rust#150990 (std: sys: net: uefi: Make TcpStream Send) - rust-lang/rust#150995 (core: ptr: split_at_mut: fix typo in safety doc) - rust-lang/rust#150998 (Relax test expectation for @__llvm_profile_runtime_user) - rust-lang/rust#151002 (Remove a workaround for a bug (take 2)) - rust-lang/rust#151005 (Fix typo in `MaybeUninit` docs) - rust-lang/rust#151011 (Update books) - rust-lang/rust#151029 (rustc-dev-guide subtree update) - rust-lang/rust#151032 (fix: added missing backtick in triagebot.toml) - rust-lang/rust#151035 (Don't suggest replacing closure parameter with type name) r? @ghost

…json-again, r=chenyukang target: fix destabilising target-spec-json cc rust-lang#151528 rust-lang#150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes rust-lang#71009

With the json target specification format destabilized in rust-lang/rust#150151, `-Zjson-target-spec` is needed for custom targets. This should resolve the CI failures seen in #1070

…c` feature JSON target specifications were destabilized in rust-lang/rust#150151

…json-again, r=chenyukang target: fix destabilising target-spec-json cc rust-lang#151528 rust-lang#150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes rust-lang#71009

JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag

…c` feature (#1455) Experimental: Update translations using AI. JSON target specifications were destabilized in rust-lang/rust#150151 Code update in #1456

…json-again, r=chenyukang target: fix destabilising target-spec-json cc rust-lang#151528 rust-lang#150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes rust-lang#71009

Rollup merge of #151534 - davidtwco:destabilise-target-spec-json-again, r=chenyukang target: fix destabilising target-spec-json cc #151528 #150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes #71009

RalfJung · 2026-02-05T17:50:01Z

So now we need to pass -Zunstable-options to rustc and -Zjson-target-spec to cargo?

It is taking me many, many tries to get this to work in Miri's CI. It's often not even clear which of the two tools is complaining about the missing flags...

ChrisDenton · 2026-02-06T08:12:15Z

So now we need to pass -Zunstable-options to rustc and -Zjson-target-spec to cargo?

It is taking me many, many tries to get this to work in Miri's CI. It's often not even clear which of the two tools is complaining about the missing flags...

Maybe that could be addressed by cargo?

destabilise target-spec-json

6c4c438

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 19, 2025

rustbot assigned JonathanBrouwer Dec 19, 2025

rustbot assigned Kivooeo Dec 19, 2025

rustbot unassigned JonathanBrouwer Dec 19, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 19, 2025

matthiaskrgr mentioned this pull request Dec 19, 2025

Rollup of 6 pull requests #150167

Closed

matthiaskrgr mentioned this pull request Dec 19, 2025

Rollup of 7 pull requests #150168

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 19, 2025

Mark-Simulacrum added the relnotes Marks issues that should be documented in the release notes of the next release. label Dec 20, 2025

rustbot mentioned this pull request Dec 20, 2025

Tracking issue for release notes of #150151: Destabilise target-spec-json #150179

Open

davidtwco mentioned this pull request Jan 5, 2026

test: add -Zunstable-options with custom targets rust-lang/cargo#16467

Merged

davidtwco added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 5, 2026

rust-bors bot merged commit a89683d into rust-lang:main Jan 13, 2026
11 checks passed

rustbot added this to the 1.94.0 milestone Jan 13, 2026

davidtwco deleted the destabilise-target-spec-json branch January 14, 2026 14:58

ehuss mentioned this pull request Jan 23, 2026

Tracking Issue for target-spec-json (flexible target specifications) #151528

Open

4 tasks

davidtwco mentioned this pull request Jan 23, 2026

target: fix destabilising target-spec-json #151534

Merged

Mark-Simulacrum mentioned this pull request Jan 25, 2026

Draft release notes for 1.94.0 #151650

Open

DeepeshWR mentioned this pull request Jan 27, 2026

rustc is not building for custom targets #151729

Open

github-actions bot mentioned this pull request Jan 28, 2026

Toolchain upgrade to nightly-2026-01-30 flux-rs/flux#1345

Draft

quaternic mentioned this pull request Feb 3, 2026

add -Zjson-target-spec to custom target workflows rust-lang/compiler-builtins#1071

Merged

phil-opp added a commit to phil-opp/blog_os that referenced this pull request Feb 3, 2026

Update 'Minimal Rust Kernel' post to enable unstable `json-target-spe…

9a1da09

…c` feature JSON target specifications were destabilized in rust-lang/rust#150151

phil-opp added a commit to phil-opp/blog_os that referenced this pull request Feb 4, 2026

Enable unstable json-target-spec feature

7345e3e

JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag

This was referenced Feb 4, 2026

Enable unstable json-target-spec feature phil-opp/blog_os#1456

Merged

Update 'Minimal Rust Kernel' post to enable unstable json-target-spec feature phil-opp/blog_os#1455

Merged

phil-opp added a commit to phil-opp/blog_os that referenced this pull request Feb 4, 2026

Enable unstable json-target-spec feature (#1456)

49f67e4

JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Destabilise `target-spec-json`#150151

Destabilise `target-spec-json`#150151
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
davidtwco:destabilise-target-spec-json

davidtwco commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025

Uh oh!

bors commented Dec 19, 2025

Uh oh!

matthiaskrgr commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025 •

edited

Loading

Uh oh!

davidtwco commented Jan 5, 2026

Uh oh!

Uh oh!

RalfJung commented Feb 5, 2026

Uh oh!

ChrisDenton commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Uh oh!

Conversation

davidtwco commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025

Uh oh!

bors commented Dec 19, 2025

Uh oh!

matthiaskrgr commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidtwco commented Jan 5, 2026

Uh oh!

Uh oh!

RalfJung commented Feb 5, 2026

Uh oh!

ChrisDenton commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Kivooeo commented Dec 19, 2025 •

edited

Loading